Looks like you need to add no-op implementations of warm() to other subclasses of WasmVm to fix the current build failures.

FYI, there is already an open PR with support for warming VMs (including other engines and tests): #280

FYI, there is already an open PR with support for warming VMs (including other engines and tests): #280

Thanks for pointing that out! I'd forgotten that existed. Looking at the two PR's I'd propose that we combine them together and "do both". As you point out, the benefit of #280 is that it provides init*Engine() impls for all engines. However, it does not instantiate wasm::Stores, which is another source of Wasm startup expense that could be performed ahead of time, while this PR does do that.

So how about we combine the two PRs:

• Add all the init*Engine() static functions and the TestVm.Init test from Add the ability to "pre-warm" Wasm engines. #280. This would give embedding code the option of initializing engines (by themselves) early, if desired.
• Add the virtual WasmVm::warm() method from this PR
• Fill in the warm() implementations for Wamr, Wasmtime, and WasmEdge classes, which should each be very similar to V8 since they are all using C-Api, i.e. instantiate a wasm::Store and store it in the (existing) store_ field.

@rachgreen33 LMK if you'd like me to create a PR that does this, or if you'd prefer to update this one yourself. Thanks!

@rachgreen33 I can rerun the workflows again, but it looks like "test with Wasmtime on Linux/s390x" is failing with:

[==========] Running 4 tests from 1 test suite.
[----------] Global test environment set-up.
[----------] 4 tests from WasmEngines/TestVm
[ RUN      ] WasmEngines/TestVm.Init/wasmtime
"cold" engine time: 64732370ns
"warm" engine time: 57047ns
test/wasm_vm_test.cc:67: Failure
Expected: (warm) <= (10000), actual: 57047 vs 10000

Full results here.

It might be necessary to adjust some of the time constants/multipliers in the new TestVm.Init test case, at least for that platform.